home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Tools (InfoMagic)
/
Internet Tools.iso
/
dos_win
/
winsock
/
maillist
/
94-05.Z
/
94-05
/
000186_news@bigblue.oit.unc.edu_Tue May 13 17:31:55 1994.msg
< prev
next >
Wrap
Internet Message Format
|
1994-05-31
|
17KB
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA06926; Fri, 13 May 1994 13:45:14 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA27631; Fri, 13 May 1994 13:31:42 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: 13 May 1994 17:31:55 GMT
From: mbc@po.CWRU.Edu (Michael B. Comet)
Message-Id: <2r0dib$pta@usenet.INS.CWRU.Edu>
Organization: Case Western Reserve University, Cleveland, OH (USA)
Sender: ses
References: <2qviju$du0@ratatosk.uninett.no>
Reply-To: mbc@po.CWRU.Edu (Michael B. Comet)
Subject: Re: WSAAsyncSelect(.., FD_WRITE | FD_READ) question!
In a previous article, spere@kyrre.hsv.no (P. Eivind Jenssen) says:
>We are having trouble with FD_READ and FD_WRITE messages!
>We would like to use the function WSAAsyncSelect() this way:
> WSAAsyncSelect(s, hWnd, READ_OR_WRITE, FD_READ | FD_WRITE);
>
>The READ_OR_WRITE message calls a function of ours.
>Our question is:
> Can one find out in this function if it was an FD_READ
> or an FD_WRITE that called the function?
>
I don't have the specs in front of me but I think the way it works
is:
Msg will be READ_OR_WRITE
wParam = socket id
lParam = LOWORD() = FD_xxxx
HIWORD() = error code
So LOWORD(lParam) should be FD_READ or FD_WRITE as you need.
--
+--------------------------------------------------------------------------+
| Michael Comet, mbc@po.CWRU.Edu - CWRU, Software Engineer/Graphics Artist |
| Computer Graphics/Animation! - Liquid Vision SIG (go liquid), Freenet |
+--------------------------------------------------------------------------+
From news@bigblue.oit.unc.edu Fri May 13 13:45:18 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA06943; Fri, 13 May 1994 13:45:18 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA34152; Fri, 13 May 1994 13:44:19 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: Fri, 13 May 1994 12:56:56
From: overbyte@acy.digex.net (overbyte)
Message-Id: <overbyte.7.000CF34F@acy.digex.net>
Organization: Shakedown Productions
Sender: ses
References: <cpunk.13.000DDDBE@halcyon.com>, <robert.396.00175A62@clark.net>, <Cpq5v5.3HJ@ucdavis.edu>
Subject: Re: is it me or does wintalk stink?
In article <Cpq5v5.3HJ@ucdavis.edu> jhframe@ucdavis.edu (Jim Frame) writes:
>From: jhframe@ucdavis.edu (Jim Frame)
>Subject: Re: is it me or does wintalk stink?
>Date: Fri, 13 May 1994 04:59:28 GMT
>In article <robert.396.00175A62@clark.net>, robert@clark.net (Robert Seidman) says:
>>It works fine for me, incoming and outgoing. I'm not sure what your setup
>>is, so I can't offer any advice. I'm very happy with it...but I do
>>wonder about the icon too!
>I've only used it outgoing, and have but one complaint (aside from the
>obnoxious icon): the incoming window has no cursor, so I have no
>indication as to whether or not the other party has paused at the end
>of a line, or issued a couple of returns (I've only used talk with one
>other person, and we "yield the floor" by sending two blank lines).
>Once the incoming window is full, I can tell by the fact that the screen
>scrolls upward that a return has been sent; but until that time, I have
>to resort to guesswork.
I havent had a problem with it. & being its a split screen ansi like chat
that hold cursor possition i dont worry about typing while the other person
is...
-The futures here, we are it, we are on our own.
Mail via POP Overbyte@acy.digex.net
SLIP @lamer.digex.net
From news@bigblue.oit.unc.edu Fri May 13 17:25:55 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA06963; Fri, 13 May 1994 13:45:21 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA19301; Fri, 13 May 1994 13:43:00 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: Fri, 13 May 1994 17:25:55 GMT
From: arnstein@netcom.com (David Arnstein)
Message-Id: <arnsteinCpr4F7.HCJ@netcom.com>
Organization: My Own Internet Account!
Sender: ses
References: <1994May12.155317.3383@megatek.com>, <arnsteinCppEAr.L72@netcom.com>, <CppIL6.vK@nntpa.cb.att.com>
Reply-To: arnstein@netcom.com
Subject: Re: 32 bit access with SCSI no available. Hunh? was Re: Win Mosaic alpha 4 (my fix)
In article <CppIL6.vK@nntpa.cb.att.com>,
na8520d00-Nichols <rnichols@ihlpm.ih.att.com> wrote:
>In article <arnsteinCppEAr.L72@netcom.com>,
>>Windows 3.1 users:
>>
>> *** J U S T S A Y N O T O S C S I ***
>
>You keep repeating this litany over and over, perhaps expecting it to
>become true by repetition alone.
>
>Windows can run just fine on SCSI system, and the presence or absence
>of 32-bit access has little effect on the performance. I run Windows
>on a SCSI system with no performance problems whatsoever.
Put your money where your mouth is. Find yourself a peecee with your
favorite SCSI host adapter and disk drive, and an IDE drive of recent
vintage. Run WinBench 4.0 to obtain disk timings on each drive. I
did. That's how I came to my conclusion: just say no to SCSI! I've
corresponded with plenty of folks who say "I'm using SCSI and it
works just fine, thank you." But if your expensive SCSI hardware
doesn't decisively outperform an IDE disk, you've wasted your time
and money.
>If you are accessing your SCSI disk via the SCSI BIOS, though, you may
>indeed have a major performance problem. For a busmastering SCSI
>adapter, this implies that you are using the double-buffering function
>of SMARTDrive, which will turn the fastest system into a dog. (This
>was the case on my own system, as the manufacturer configured it.)
>What you desperately need is an ASPI driver that either (a) supports
>the virtual DMA interface directly, or (b) provides the necessary
>buffering itself. This will allow you to get rid of the SMARTDRV
>/DOUBLE_BUFFER line in your CONFIG.SYS. Furthermore, the SCSI BIOS is
>no longer used once the ASPI driver is installed. This eliminates
>another performance bottleneck since it is often impossible to enable
>shadowing for the SCSI BIOS, forcing the CPU to run directly from the
>8-bit EPROM. (In busmastering controllers, a portion of this address
>range is used as a mailbox and must be writable. Most motherboards do
>not allow you to shadow a range of addresses and still be able to
>perform writes there.)
I have a Future Domain SCSI host adapter. It does not do
busmastering, it uses programmed I/O (PIO). Therefore, I don't need
double buffering. I don't use it. If your ASPI driver is a DOS TSR,
it must still run in real mode, so you're still paying the (large)
performance penalty for switching between protected mode and real
mode. By the way, busmastering SCSI host adapters cause problems
when used with floppy port tape drives (QIC 40 and QIC 80 standard).
This is because of the crappy support for DMA provided by the
industry standard architecture. If you use such a tape drive, you'll
have to fiddle with the "bus on" time of your SCSI host adapter,
complicating your life and further degrading SCSI I/O speed.
Maybe I should ditch my Future Domain h.a. in favor of Adaptec,
apparently that's what you're using. But Adaptec is expensive, and
the magazine reviews I've seen indicate that the Future Domain 1680
(my h.a.) is a speedy product.
>If you cannot obtain a driver that will permit you to eliminate
>SMARTDrive's double buffering, then I would have to agree with your
>"JUST SAY NO" advice -- for that particular SCSI adapter, anyway.
>
>(BTW, to the best of my knowledge, the ASPI drivers in the
>CorelSCSI! package do NOT allow you to eliminate SMARTDrive's double
>buffering. Adaptec's ASPI4DOS has a switch to provide the necessary
>buffering itself, as do the drivers for DTC's busmastering SCSI
>adapters. For the Buslogic BT747S, the drivers perform the necessary
>functions automatically, with no explicit switch required. I have no
>experience with other SCSI adapters.)
--
David Arnstein | What do you mean, "get a life"?
arnstein@netcom.com | This *is* my life!
From news@bigblue.oit.unc.edu Fri May 13 14:15:10 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA13623; Fri, 13 May 1994 14:15:10 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA34154; Fri, 13 May 1994 13:45:14 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: Fri, 13 May 1994 12:59:33
From: overbyte@acy.digex.net (overbyte)
Message-Id: <overbyte.8.000CFE75@acy.digex.net>
Organization: Shakedown Productions
Sender: ses
References: <2qv4hk$161f@inca.gate.net>, <2qvtlj$5e5@news.csie.nctu.edu.tw>
Subject: Re: alt.winsock.binaries???
In article <2qvtlj$5e5@news.csie.nctu.edu.tw> jenwen@pdd.iii.org.tw (Jenwen) writes:
>From: jenwen@pdd.iii.org.tw (Jenwen)
>Subject: Re: alt.winsock.binaries???
>Date: 13 May 1994 13:00:35 GMT
>Nickolas (Nickolas@inca.gate.net) wrote:
>: Hello people,
>:
>: I was thinking how about making a group for binary posting?
>: It would better for some one who wants to release there winsock
>: software. Just a thought ;)
>:
>: Nickolas@inca.gate.net
>I agree!! Since it seem so many ask where Trumpet? where ..
>Jenwen,Chien-Wen Huang
>jenwen@netrd.net.tw
I secound that! I think a WINSOCK only binary groupe would be great since
most of thew stuff is beta & buggy why mix it up in an enormous news group.
leave it specialized...
-The futures here, we are it, we are on our own.
Mail via POP Overbyte@acy.digex.net
SLIP @lamer.digex.net
From news@bigblue.oit.unc.edu Fri May 13 17:30:11 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA13633; Fri, 13 May 1994 14:15:12 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA12213; Fri, 13 May 1994 13:52:17 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: Fri, 13 May 1994 17:30:11 GMT
From: arnstein@netcom.com (David Arnstein)
Message-Id: <arnsteinCpr4MC.HL5@netcom.com>
Organization: My Own Internet Account!
Sender: ses
References: <arnsteinCppEAr.L72@netcom.com>, <CppIL6.vK@nntpa.cb.att.com>, <2quet0$8u3@bmerha64.bnr.ca>
Reply-To: arnstein@netcom.com
Subject: Re: 32 bit access with SCSI not avail. -> Adaptec questions.
In article <2quet0$8u3@bmerha64.bnr.ca>, Jeff Hayes <jjhayes@bnr.ca> wrote:
>
>_]What you desperately need is an ASPI driver that either (a) supports
>_]the virtual DMA interface directly, or (b) provides the necessary
>_]buffering itself. This will allow you to get rid of the SMARTDRV
>_]/DOUBLE_BUFFER line in your CONFIG.SYS.
> Adaptec docs say to remove the /DOUBLE_BUFFER, set VirtualHDIRQ=off
>in system.ini to make everything happy in Windows.
>
>_]Adaptec's ASPI4DOS has a switch to provide the necessary
>_]buffering itself
> I have the Adaptec docs here in front of me and there is no
>switch to enable buffering in aspi4dos. Neither do any of the other 3
>drivers. Hummm.
>
> So...
>
> The questions to answer (Adaptec's docs do not) are:
>
> Do the Adaptec drivers support VDMA?
> Do they do there own buffering?
> Is there buffering cache on the ctlr board?
Just listen to all this complexity! If you have the guts, do a
quantitative comparison of speed of your SCSI nightmare with an IDE
drive - while running Windows 3.1. Have you gained any speed?
--
David Arnstein | What do you mean, "get a life"?
arnstein@netcom.com | This *is* my life!
From news@bigblue.oit.unc.edu Fri May 13 15:27:41 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA13648; Fri, 13 May 1994 14:15:15 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA19019; Fri, 13 May 1994 14:12:14 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: Fri, 13 May 94 15:27:41 GMT
From: cbarton@clark.dgim.doc.ca (Casey Barton)
Message-Id: <cbarton.115.2DD39C6A@clark.dgim.doc.ca>
Organization: None
Sender: ses
References: <toreh.24.2DC76C31@bootes.sds.no>, <jones.35.0017A7E6@cbdb1.nimh.nih.gov>, <toreh.1.2DD37539@bootes.sds.no>
Subject: Re: The purpose of this news group: netsurfing?
toreh@bootes.sds.no (Tore Haraldsen) writes:
>Well, since this news group started out as a continuation of the
>corresponding winsock mailing-list, I do not think my question was
>impertinent. This group WAS alt.winsock.programming!
Well, it underwent a spontaneous name change then. It now seems to be
called alt.winsock.
>This group WAS supposed to be the forum for specialized questions around
>winsock programming.
Regardless of initial intentions, this group is now fulfilling a useful
niche -- winsock applications are probably the single fastest growing group of
internet access software around, and a common forum for discussion is useful.
In fact, I believe that a comp.*.winsock would be fully justified...
A group specifically for winsock *programming* should, logically, be
called *.winsock.programming, no? There's certainly a demand for it. Why
don't you initiate the process of creating it, instead of stating that nearly
everybody that is making good use of this group should be somewhere else?
>What I was trying to say (and maybe I did not make it clear enough), is the
>obvious lack of a news group for connectivity & utilities discussions. This
>group is not the only one , others being comp.protocol.nfs,
>comp.protocol.tcpip.* etc.
>
>So I tried to suggest we need a specialized group for connectivity &
>utilities: alt.winsurf or alt.netsurf may be.
But the bulk of non-programming-related posts here are not simply generic
"netsurfing" questions -- they are *winsock* specific. So they certainly have
a place here. Perhaps a generic "netsurf" group would be useful as well,
though I suspect that alt.netsurf is a little too generic. At any rate, any
such group should be created in *addition* to this group, not in place of it.
+-----------------------------------------------------------------------------+
| Casey Barton (a guy) cbarton@clark.dgim.doc.ca |
| http://pctcp132.dgcp.doc.ca/personal/index.html |
From news@bigblue.oit.unc.edu Fri May 13 16:30:03 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA21702; Fri, 13 May 1994 14:45:10 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA23923; Fri, 13 May 1994 14:21:02 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: Fri, 13 May 1994 16:30:03 GMT
From: cpm@uplx.co.uk (Chris P Murray)
Message-Id: <Cpr1u5.6pI@uniplex.co.uk>
Organization: Uniplex Ltd.
Sender: ses
References: <2qtem9$il3@debbie.cc.nctu.edu.tw>
Subject: Re: Why connect error?
u8234514@cc.nctu.edu.tw wrote:
: sockfd = socket(AF_INET, SOCK_STREAM, 0)
: If (sockfd <= 0) Then
: MsgBox ("Open socket error!")
: End If
: dest.sin_family = AF_INET
: dest.sin_addr = inet_addr(txtHost.Text)
: dest.sin_port = htons(Val(txtPort.Text))
: destlen = 15
: If (connect(sockfd, dest, destlen) < 0) Then
: MsgBox ("Connect Error")
: End If
I'm assuming 'dest' is correctly defined as:
struct sockaddr_in dest;
then try:
sockfd = socket(AF_INET, SOCK_STREAM, 0)
If (sockfd < 0) Then
MsgBox ("Open socket error!")
End If
bzero((char *) &dest, sizeof(dest));
dest.sin_family = AF_INET
dest.sin_addr = inet_addr(txtHost.Text)
dest.sin_port = htons(Val(txtPort.Text))
If (connect(sockfd, (struct sockaddr *) &dest, sizeof(dest)) < 0) Then
MsgBox ("Connect Error")
(Note the 'If (sockfd < 0)' test should be '< 0' not '<= 0' as it could
return fd 0 is you've close stdin)